1. Technical Field
The present invention relates to a method of signal handling in a computer system, a computer system for executing the method, and a computer program product containing code portions to execute the method.
2. Description of the Related Art
The IBM® Power® System (System i® model) runs the IBM i5/OS® host operating system, which manages multiple i5/OS operating system processes. An operating system process is program code in execution including a set of resources, such as pending signals, an address space, a data section containing global variables, and one or more threads of execution. Threads of execution, often shortened to threads, are the objects of activity within the process. The first thread in the process is referred to as the initial or primary thread. Some processes are capable of supporting additional threads, which are called secondary threads. Processes that allow more than one thread of execution are called multi-threaded in contrast with single-threaded processes.
The IBM® i5/OS® Portable Application Solutions Environment (i5/OS PASE) is based on the i5/OS host operating system and is able to execute system code portions of the IBM operating system AIX® (Advanced Interactive eXecutive) natively within the i5/OS operating system process. The AIX operating system is a UNIX derivative targeting high performing server systems. Since the AIX operating system is embedded in the i5/OS host operating system, it is defined as PASE (AIX) guest operating system. The invocation stack of a specific thread of the host operating system process running instructions of the guest operating system shows stack frames pointing to code portions of both the host operating system and the guest operating system.
The Integrated Language Environment (ILE) architecture of the i5/OS operating system provides a set of application programming interfaces (APIs) known as ILE Common Execution Environment (CEE) APIs useful for mixed-language applications because they are independent of high-level languages.
In the case of the i5/OS host operating system, a database system, named DB2 for i5/OS, is integrated in the i5/OS host operating system. The i5/OS host operating system including the database system and the embedded guest operating system PASE(AIX) are installed on one computer system host, for example IBM® Power® System. To perform a database operation on the built-in database, an application programmer or a user can issue a system call of the i5/OS host operating system by way of the ILE application programming interface. This database operation is blocking the host operating system process until the database operation has been completed.
The database system may also reside on a remote system host, which can have an arbitrary operating system. Since the local system host and the remote system host are connected by means of a network, the database access is a socket I/O operation. Since the client and server component of the database driver are installed on different hosts, the system call is not blocking and can be interrupted on the client side while the database operation on the server side is still being executed.
In an operating system, signals are used to notify a process or thread of a particular asynchronous event. The signals are often described as software interrupts. Asynchronous signals are a means of communication between concurrent processes or between multiple threads within a single process. When a specific signal is sent to a process or thread, the process or thread catches the signal and executes code portions of the application dedicated to handling the signal. These code portions are also called signal handler. The signal handling depends on the disposition of the signal, which may be characterized by a signal number. The handling of the signal in an operating system is similar to a hardware system entering an interrupt handler as the result of receiving an interrupt.
Signals generated by some action attributable to a particular thread are sent to the thread that caused the signal to be generated. Signals generated in association with a process ID, a process group ID, or an asynchronous event, such as a terminal activity, are sent to the process. The POSIX compliant subroutine pthread_kill( ) sends a signal to a thread. Because thread IDs identify threads within a process, this subroutine can only send signals to threads within the same process. The POSIX compliant subroutine kill( ) and thus the kill command, sends a signal to a process. Signals to processes can be sent from another process or the destination process itself.
Multi-threaded computer program applications can provide real-time signal handling in a single operating system environment. A common way of handling asynchronous signals in a multi-threaded program is to mask signals in all the threads of an operating system process, and then create at least one separate thread in the same process whose sole purpose is to wait for signals, to catch, and to handle them.
Signal masks are maintained at thread level. When the operating system processes a signal destined for a specific thread and the thread is masked to this type of the signal, the operating system does not forward the signal. When the signal is sent to a specific process and all threads of the process are masked to this type of the signal, the signal will not be delivered either. When more than one thread are not masked to this type of the signal, one of these threads will catch the signal and invoke signal handling. Each thread can have its own set of signals which can be masked and will be blocked from delivery to the thread. The POSIX compliant subroutine pthread_sigmask( ) is used to get and set the calling thread's signal mask.
Signal handlers are maintained at process level. This means that all threads of a process would run the same instructions when a signal is sent to any of the threads. As mentioned here above, programs might create a dedicated thread to wait for asynchronously generated signals. The POSIX compliant subroutine sigwait( ) blocks the calling thread until one of the awaited signals is sent to the process or to the thread.
The operating system allows explicit communication between threads by means of sending signals, and implicit communication through the modification of shared data. To protect data or other resources from concurrent access by multiple threads at any point of time, the operating system may provide a set of synchronization objects, such as mutex, condition variable, read/write lock, or join. A mutex is a mutual exclusion lock. Only one thread can acquire and hold the lock at one point of time, and only the owner of this thread is able to release the mutex so that the same or another thread can acquire it again.
Signal processing becomes intricate in the i5/OS PASE environment because the i5/OS host operating system process is on one hand executing code portions of the application or of the PASE (AIX) guest operating system and on the other hand performing system calls of the host operating system. The operating system process executes code portions of the guest operating system when the application issues system calls of the guest operating system.
When a signal is sent from the guest operating system to the operating system process, i.e., by executing a system call of the guest operating system, then the process catches the signal and invokes the signal handler of the guest operating system. When a signal is sent from the host operating system to the operating system process, i.e., by executing a system call of the host operating system, the process also catches the signal and invokes the signal handler of the host operating system.
The prior art implementation of the PASE (AIX) guest operating system embedded in the i5/OS host operating system allows to set an i5/OS environment variable QIBM_PASE_MAP_SIGNALS to a specific value (uppercase character “I”) so that the default signal handler of the i5/OS host operating system maps a signal, which the process caught from the host operating system, to the guest operating system, i.e., the signal handler of the host operating system invokes the signal handler of the guest operating system, immediately, even though the thread of the process that caught the signal, may be masked to signals from the guest operating system.
When a specific thread of the operating system process invokes a system call of the i5/OS host operating system for a non-masked operation, for example, a socket I/O operation, the process can catch a specific signal from the host operating system and the thread that caught the signal executes the default signal handler of the host operating system. If the i5/OS environment variable QIBM_PASE_MAP_SIGNALS is set to the specific value, the default signal handler maps the signal from the host operating system to the guest operating system and the guest operating system forces the thread to execute the signal handler of the guest operating system.
When the specific thread executes a system call of the host operating system to perform a native masked operation, for example, a database request to the integrated database system, the thread is masked to signals from the host operating system. In this case, the thread cannot catch a signal from the host operating system and invoke the default signal handler of the host operating system. The signal will be pending until the host operating system process becomes unmasked, i.e., after the database operation has completed. Then the signal may be processed by the signal handler of the host operating system and possibly by the signal handler of the guest operating system depending on the environment variable QIBM_PASE_MAP_SIGNALS. This means that the host operating system process would not be able to handle the caught signal, which the host operating system sent to the operating system process, in a deterministic response time.
When a specific thread of the i5/OS host operating system process is executing a system call of the host operating system by way of the ILE API, the thread may be masked to signals from the guest operating system. When the thread catches a signal from the guest operating system, the signal is held pending until the thread unmasks itself to signals from the guest operating system. Unfortunately, the handling of the caught signal, which the guest operating system sent to the operating system process, will also be delayed in time.
The semantics of the business application SAP® R/3® and mySAP.com®, which is running in the i5/OS PASE operating system, is single-threaded. This means that an operating system process of the application must not have more than one thread executing application code portions and performing system calls of the guest operating system at any given point of time.
The requirement of single-threaded application execution in a multi-threaded operating system complicates a possible solution to the problem of partly immediate and partly delayed signal delivery described in the sections above.